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SYSTEM FOR SHARING RESOURCES AMONG RSVP 

SESSIONS 

BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to computer networks and, more specifically to the reserva- 
tion of bandwidth in computer networks. 

Background Information 

Computer networks typically comprise a plurality of interconnected entities. An 
entity may consist of any device, such as a computer or end station, that "sources" (i.e., 
transmits) or "sinks" (i.e., receives) datagrams (e.g., packets and/or frames). A common 
type of computer network is a local area network ("LAN") which typically refers to a 
privately owned network within a single building or campus. LANs typically employ a 
data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that 
defines the functions performed by the data link and physical layers of a communications 
architecture (i.e., a protocol stack). In many instances, several LANs may be intercon- 
nected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a 
wide area network ("WAN") or intranet that may span an entire country or continent. 

One or more intermediate network devices are often used to couple LANs to- 
gether and allow the corresponding entities to exchange information. For example, a 
bridge may be used to provide a "bridging" function between two or more LANs. Alter- 
natively, a switch may be utilized to provide a "switching" function for transferring in- 
formation between a plurality of LANs or end stations. Bridges and switches may oper- 
ate at various levels of the communication protocol stack. For example, a switch may 
operate at layer 2 which, in the Open Systems Interconnection (OSI) Reference Model, is 
called the data link layer and includes the Logical Link Control (LLC) and Media Access 
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Control (MAC) sub-layers. Data frames at the data link layer typically include a header 
containing the MAC address of the entity sourcing the message, referred to as the source 
address, and the MAC address of the entity to whom the message is being sent, referred 
to as the destination address. To perform the switching function, layer 2 switches exam- 
ine the MAC destination address of each data frame received on a source port. The frame 
is then switched onto the destination port(s) associated with that MAC destination ad- 
dress. 

Other network devices, commonly referred to as routers, may operate at higher 
communication layers, such as layers 3 and 4 of the OSI Reference Model, which in 
Transmission Control Protocol/Internet Protocol (TCP/IP) networks corresponds to the IP 
and the TCP/User Datagram Protocol (TCP/UDP) layers. Data frames at the IP layer in- 
clude a header which contains an IP source address and an IP destination address, while 
frames at the TCP/UDP layer include source and destination port numbers. Routers or 
layer 3 switches may re-assemble or convert received data frames from one LAN stan- 
dard (e.g., Ethernet) to another (e.g. token ring). Thus, layer 3 devices are often used to 
interconnect dissimilar subnetworks. 

Voice over IP rVoIP) 

Traditionally, computer networks were used to exchange static files or data, such 
as text and spreadsheet files, while the Public Switched Telephone Network (PSTN) was 
used to exchange voice information. Computer networks, however, are increasingly be- 
ing used to transport "voice" information. Voice over IP (VoIP) typically refers to a 
group of technologies used to transmit voice information over computer networks. Such 
networks include a plurality of voice agents that convert voice information from its tradi- 
tional telephony form to a form that is suitable for packet transmission. In other words, 
the voice agent encodes, compresses and encapsulates the voice information into a plu- 
rality of data packets. Examples of voice agents include IP telephones, VoIP gateways, 
certain private branch exchanges (PBXs), personal computers (PCs) running communi- 
cation applications, network devices providing voice gateway services, etc. A calling 
party uses a voice agent to initiate a VoIP call. Once the voice information has been con- 
verted into packet format, it is carried by the computer network to a second voice agent 
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configured to serve the called party. Voice traffic, unlike static data files or records, is 
highly sensitive to delay and to lost packets. That is, delays in receiving data packets car- 
rying voice information at the called party's voice agent can seriously degrade the quality 
of the call. Accordingly, packets carrying voice information must be delivered to the 
called party with high probability and in a timely manner. 

Computer networks include numerous services and resources for use in forward- 
ing network traffic. For example, different network links, such as Fast Ethernet, Asyn- 
chronous Transfer Mode (ATM) channels, SONET links, satellite links, etc., offer differ- 
ent speed and bandwidth capabilities. Particular intermediate devices also include spe- 
cific resources or services, such as priority queues, filter settings, traffic shapers, queue 
selection strategies, congestion control algorithms, etc. that affect the rate at which traffic 
moves through the device and thus across the network. Depending on the selection or 
allocation of such resources or services, network traffic for different sources and sinks 
can be forwarded at different speeds or rates, thereby controlling the loss and/or delay 
experienced by the traffic. 

The Resource Reservation Protocol 

As set forth above, to support VoIP, packets carrying voice information must 
typically be delivered within narrow time constraints. Although many computer net- 
works have the resources and services to meet the delivery requirements of VoIP, these 
resources and services must be allocated, preferably in advance, to the correct network 
traffic. The Resource reSerVation Protocol (RSVP), which is set forth at RFC 2205, is a 
signaling protocol that was developed so that entities (typically referred to as receivers) 
could reserve bandwidth within their computer networks to receive from one or more 
sourcing entities a desired traffic flow, such as multimedia stream. Pursuant to RSVP, 
sources send RSVP Path messages identifying themselves and indicating the bandwidth 
needed to receive their programming or content. These messages proceed hop-by-hop 
through the intermediate network devices, making those devices aware of the possibility 
that a reservation of resources may be required. If a receiver is interested in the pro- 
gramming or content offered by a particular source, it responds with a RSVP Reservation 
(Resv) message, which travels hop-by-hop back to the source. At each hop, the corre- 
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sponding intermediate device establishes a session for the receiver and sets aside suffi- 
cient resources to provide the requested bandwidth for the desired traffic flow. These 
resources are immediately made available to the traffic flow. If the resources are not 
available, the reservation is refused explicitly so that the receiver knows it cannot depend 
on the corresponding resources being devoted to its traffic. By using RSVP, packets car- 
rying voice information can be accorded the resources and services they need to ensure 
timely delivery. 

VoIP telephones and voice applications are increasingly being offered with 
greater feature sets. One such feature is "call waiting", which is a common service or 
feature of conventional, analog telephone sets. With call waiting, a first party who is on 
the phone with a second party is alerted to an incoming call from a third party. The first 
party can put the second party on hold and answer the call from the third party. The first 
party can even alternate back and forth between second and third parties. VoIP tele- 
phones and voice applications support of call waiting, however, can create potential 
problems, such as the setting aside of resources unnecessarily. 

In particular, the VoIP telephone or application will typically use RSVP to reserve 
separate resources along the entire route to both the second and third parties to support 
the two calls. However, because call waiting only allows the first party to talk to either 
the second or the third party at any given point in time, only one set of the resources will 
be in use at any instant. That is, at any given time, the VoIP telephone or application will 
be generating packets for forwarding to either the second party or the third party, but not 
both. Nonetheless, resources will remain reserved to support traffic to both the second 
and third parties at all times. As a result, resources that could be applied to other traffic 
are wasted. In addition, the request to reserve resources for the third party may fail ad- 
mission control at one or more devices along that portion of the route shared with the 
second party even though a separate set of resources are really not required. This would 
result in the voice traffic to or from the third party being denied access to adequate re- 
sources and thus severely degrading the "quality" of the call, even though resources set 
aside for the second party remain idle. 
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SUMMARY OF THE INVENTION 

Briefly, the present invention relates to a system that associates discrete traffic 
flows or sessions within a computer network with a group, and allows the traffic flows or 
sessions corresponding to a given group to share a single set of network resources. Spe- 
cifically, when a sourcing entity, such as a voice agent, requests resources to be reserved 
within the computer network for a first session, i.e., a traffic flow directed to a first re- 
ceiving entity, the sourcing entity generates a locally unique resource identifier (ID). The 
sourcing entity then uses this resource ID in its request to reserve resources for the first 
traffic flow. Intermediate network devices within the computer network reserve a set of 
resources and associate the reservation with the specified resource ID. The sourcing en- 
tity may then reuse this same resource ID in another reservation request for a second ses- 
sion, i.e., a traffic flow directed to a second receiving entity. In accordance with the pre- 
sent invention, intermediate network devices are configured to recognize that a reserva- 
tion made by the sourcing entity and associated with this resource ID already exists. The 
intermediate devices are further configured to share the previously reserved resources 
between the first and second sessions, rather than reserve additional or further resources 
for the second session. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention description below refers to the accompanying drawings, of which: 
Fig. 1 is a highly schematic diagram of a computer network; 
Fig. 2 is a highly schematic block diagram of a voice agent in accordance with the 
present invention; 

Fig. 3 is a highly schematic block diagram of an intermediate network device in 
accordance with the present invention; 

Figs. 4A-D is a flow diagram of the method of the present invention; 

Fig. 5 is a highly schematic diagram of a network reservation message in accor- 
dance with the present invention; and 

Fig. 6 is a highly schematic diagram of a data structure in accordance with the 
present invention. 
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DETAILED DESCRIPTION OF AN ILLUSTRATIVE 

EMBODIMENT 

Fig. 1 is a highly schematic diagram of a computer network 100, The network 
100 includes first, second and third voice agents 102, 104, 106 that are interconnected by 
a plurality of intermediate network devices. More specifically, first voice agent 102 is 
coupled to a first hop network device, such as router 108, which, in turn, is coupled to a 
second network device, such as router 110. Router 1 10, in turn, is coupled to a network 
cloud 112. The network cloud 1 12 may consist of a plurality of network devices, local 
area networks (LANs), and end stations. Second voice agent 104 is coupled to a first hop 
network device, such as router 114, which is coupled to router 116. Router 1 1 6, in turn, 
is coupled to network cloud 112. Third voice agent 106 is coupled to router 116. 

In the illustrative embodiment, voice agents 102, 104, 106 are intermediate net- 
work devices 1 18-120 that have been configured to provide VoIP gateway support to 
other devices or entities, such as conventional analog telephone sets 122-124, coupled 
thereto. Suitable VoIP gateway devices include the 3600 series of routers from Cisco 
Systems, Inc. of San Jose, California. 

It should be understood that the network configuration 100 of Fig. 1 is for illus- 
trative purposes only and that the present invention will operate with other, possibly far 
more complex, network topologies. 

Fig. 2 is a highly schematic, partial block diagram of a voice agent, such as 
voice agent 102. Voice agent 102, more specifically device 118, preferably includes a 
communication facility 202 and one or more resource reservation components, such as 
a Resource reSerVation Protocol (RSVP) entity or engine 204, As described herein, the 
RSVP entity 204, which includes a RSVP message generator 206 and a RSVP state ma- 
chine engine 208, operates, except as described herein, in accordance with the RSVP 
specification standard, which is set forth at RFC 2205 and is hereby incorporated by ref- 
erence in its entirety. Voice agent 102 further includes a call signaling entity 210 in 
communicating relationship with the RSVP entity 204 and the communication facility 
202. Entity 210 operates in accordance with a signaling protocol, such as H323, Ses- 
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sion Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP) or MEGACO, 
which is an extension of MGCP. The RSVP entity 204 is also in communicating rela- 
tionship with the communication facility 202, and can thus exchange information, in- 
cluding network packets and frames with facility 202. In accordance with the present 
invention, RSVP entity 204 further includes a resource identifier (ID) generator 212. 
As described below, resource ID generator 212 is configured to generate IDs for use by 
the RSVP entity 204 in reserving resources within computer network 100 (Fig. 1). 

The communication facility 202 preferably includes one or more software li- 
braries for implementing a communication protocol stack allowing voice agent 102 to 
exchange messages with other entities of network 100, such as voice agents 104 and/or 
106. The communication facility 202 may, for example, include software layers corre- 
sponding to the Transmission Control Protocol/Internet Protocol (TCP/IP) communica- 
tion stack, although other communication protocols, such as Asynchronous Transfer 
Mode (ATM) cells, the Internet Packet Exchange (IPX) protocol, the AppleTalk protocol, 
the DECNet protocol and/or NetBIOS Extended User Interface (NetBEUI) could be util- 
ized. Communication facility 202 further includes transmitting and receiving circuitry 
and components, including one or more network interface cards (NICs) that establish 
one or more physical ports for exchanging data packets and frames with router 108 to 
which it is connected. 

In accordance with the preferred embodiment, voice agent 102 includes pro- 
grammable processing elements (not shown), which may contain software program in- 
structions pertaining to the methods of the present invention. Other computer readable 
media may also be used to store the program instructions of the present invention. 

Fig. 3 is a highly schematic, partial, functional block diagram of an intermediate 
network device in accordance with the present invention, such as router 108, which is the 
first hop router from voice agent 102. Router 108 preferably includes one or more 
packet/frame receiver transmitter object 302, a traffic scheduler 304, and a forwarding 
engine 305. The packet/frame receiver transmitter object 302 is preferably configured to 
provide one or more interfaces or ports for receiving and sending network messages by 
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router 108. The traffic scheduler 304 includes a plurality of resources or services that are 
used by router 108 to forward packets. For example, scheduler 304 may include one or 
more metering entities 306, one or more marker entities 308, one or more shaper entities 
309, one or more dropper entities 310, and one or more queue selector entities 312. The 
queue selector entity 312, moreover, includes or has access to a plurality of queues 314a- 
d which buffer packets for the interfaces and/or ports that have been configured at router 
108. The packet/frame receiver transmitter object 302, the traffic scheduler 304, and 
forwarding engine 305 are in communicating relationship with each other via one or 
more communication paths or bus structures, such as system bus 3 15, so that network 
messages as well as commands may be exchanged between them. 

Router 108 further includes one or more resource allocation and reservation com- 
ponents. In the preferred embodiment, router 108 includes a RSVP entity or engine 316, 
a packet/frame classification engine 318, and an admission control entity 320. The RSVP 
engine 316, moreover, includes a RSVP message generator 322, a RSVP state machine 
engine 324 and a data structure 600 for storing RSVP information. RSVP engine 316 
similarly operates, except as described herein, in accordance with the RFC 2205 specifi- 
cation standard. Router 108 also includes programmable processing elements (not 
shown), which may contain software program instructions pertaining to the methods of 
the present invention. Other computer readable media may also be used to store the 
program instructions of the present invention. 

A suitable platform for router 108 is the 7200 or 4700 series of routers from Cisco 
Systems, Inc. Nonetheless, those skilled in the art will recognize that the present inven- 
tion, or parts thereof, may be implemented in other network devices and/or entities, such 
as switches, router-switches, bridges, repeaters, servers, etc. 

Figs. 4A-D is a flow diagram of the method of the present invention. Suppose, 
for example, that a first party utilizes voice agent 102 (Fig. 1) to place a call to a second 
party at voice agent 104. The first party may dial a series of numbers at the analog tele- 
phone set 122 that correspond to voice agent 104. To insure that the anticipated voice 
traffic from voice agent 102 is forwarded through the computer network 100 in a timely 
manner, i.e., with minimal delay, voice agent 102 (in cooperation with agent 104 as de- 
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scribed below) preferably causes sufficient resources to be reserved across the computer 
network 100 to meet the time constraints of voice traffic. Preferably, the call signaling 
entity 210 at device 118 detects the start of a call from telephone set 122 to voice agent 
104, as indicated at block 402 (Fig. 4A). 

5 In response, voice agent 102 generates a locally unique resource ID value, e.g., 

"42578", for use with the reservation of network resources about to be made for the ses- 
sion with voice agent 104, as indicated at block 404. In this context, "locally unique" 
means that the chosen resource ID value is not currently in use by voice agent 102 for 
any other call. Call signaling entity 210 may, for example, issue one or more Application 

10 Programming Interface (API) system calls to RSVP entity 204 causing it to have the re- 
source ID generator 212 produce a resource ID value. The resource ID generator 212 
may be configured as a random number generator for producing 32-bit strings. The 
RSVP message generator 206 then formulates one or more RSVP Path messages that in- 
corporate the generated resource ID value, as indicated at block 406. Another API sys- 

15 tern call may be used by the call signaling entity 210 to direct the RSVP entity 204 to 
generate the Path message. 

Fig. 5 is a schematic block diagram of a Path message 500 in accordance with the 
present invention. The Path message 500 includes a header 502, a sender Template ob- 
ject 504, a sender Tspec object 506, a session object 508 and a resource ID object 510, 

20 each of which has a plurality of fields. In particular, the header 502 has a version field 
512, a flags field 514, a message type field 516, a RSVP checksum field 518, a Send 
Time To Live (TTL) field 520, a reserved field 522 and a RSVP length field 524. The 
sender Template object 504 has a length field 526 (loaded with the length of the respec- 
tive object), a class number field (C-Num) 528 and a class type (C-type) field 530. It 

25 further includes an IP source address (SA) field 532, a source port number field 534 and 
may include one or more un-used fields. 

The sender Tspec object 506 includes length field 536, class number and class 
type fields 538, 540. It further includes a token bucket rate field 542, a token bucket size 
field 544, a peak data rate field 546, a minimum policed unit field 548 and a maximum 
30 packet size field 550, among others. The session object 508 includes length, class num- 
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ber and class type fields 552 ? 554, 556. It further includes IP destination address (DA) 
and destination port fields 558, 560. The resource ID object 510 includes length, class 
number and class type fields 562, 564, 566. It further includes a resource ID field 568. 

Message generator 206 loads header 502, sender Template object 504, sender 
5 Tspec object 506, and session object 508 in a conventional manner. In particular, it loads 
the IP SA and source port fields 532, 534 with the IP address and Transmission Control 
Protocol/User Datagram Protocol (TCP/UDP) port being utilized by voice agent 102. It 
similarly loads the IP DA and destination port fields 558, 560 with the IP address and 
TCP/UDP port (if known) for voice agent 104. Message generator 206 loads the sender 
10 Tspec object 506 with values corresponding to the network resources, e.g., the band- 
width, that voice agent 102 believes will be required to support the anticipated traffic 
flow to voice agent 104. The value generated by the resource ID generator 212, i.e., 
42578, is loaded into the resource ID field 568 of object 510. Class number and class 
type fields 564, 566 of object 510 are preferably loaded with preselected values which 
is suitably configured network devices and entities recognize as indicating that object 510 
carries a resource ID for use as described herein. 

It should be understood that Path message 500 may include other objects, such as 
an adspec object carrying parameters that may be used to characterize the path taken by 
the traffic flow or session. 

20 The RSVP entity 204 then passes the Path message 500 to the voice agent's 

communication facility 202 for transmission toward voice agent 104 via network 100, as 
indicated at block 408. The Path message 500 is first received at router 108. The 
packet/frame receiver transmitter object 302 of router 108 recognizes the received mes- 
sage as an RSVP Path message and, accordingly, passes it to the RSVP engine 316 for 

25 processing, as indicated at block 410. The RSVP engine 316 stores the contents of the 
Path message 500 in data structure 600, as indicated at block 412. 

Fig. 6 is a highly schematic illustration of data structure 600 configured as a 
RSVP session table or array. RSVP session table 600 includes a plurality of columns 
602-612 and rows 616a-f whose intersections define corresponding records or cells of the 
30 table. Specifically, table 600 includes a source address (SA) column 602, a resource ID 
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column 604, a source port column 606, a destination address (DA) column 608, a desti- 
nation port column 610, and a previous hop address column 612. As described below, 
the SA and resource ID columns 602, 604 can be logically combined to form a session 
group ID, as indicated by column 614. Each row 616a-f of table 600 preferably corre- 
5 sponds to a respective RSVP session. 

It should be understood that RSVP session table 600 may include additional in- 
formation, such as whether or not resources have been reserved for the respective ses- 
sions, the reserved bandwidth, etc. 

RSVP engine 316 first establishes a new row or entry, e.g., row 616a, for the traf- 
10 fic flow or session with voice agent 104. The RSVP engine 316 then populates the cells 
or records of this entry 616a with the contents of the received Path message 500. For ex- 
ample, RSVP engine 316 loads the source address and source port from fields 532, 534 
into the cells of table entry 616a that correspond to columns 602, 606. It loads the desti- 
nation address and destination port from fields 558, 560 into the cells that correspond to 
is columns 608, 610. It loads the address of the previous hop node into the cell corre- 
sponding to column 612, and it loads the resource ID value from field 568, i.e., 42578, 
into the cell corresponding to column 604. 

Router 108 then loads its IP address into a previous hop object (not shown) that it 
adds to the Path message 500 and forwards the message 500 toward voice agent 104, as 

20 indicated at block 414 (Fig. 4A). Router 1 08 may consult a routing table (not shown) to 
determine the interface from which the Path message 500 is to be forwarded. At each 
hop along the route to voice agent 104, the respective intermediate network device proc- 
esses the Path message in the same manner as described above. In particular, each device 
stores the information contained in the Path message 500 in its RSVP session table 600. 

25 Each intermediate device also loads its IP address into the previous hop object before 
forwarding the Path message 500 to the next intermediate network device along the route. 
Thus, when the Path message 500 reaches its destination (e.g., voice agent 104), each in- 
termediate network device along the route from the sourcing entity will have stored the 
address of the previous hop along that route so that it will be able to forward messages 

30 back to the sourcing entity along the same route used by the Path message 500. 
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Voice agent 104 preferably responds to the Path message 500 by generating one 
or more RSVP Reservation (Resv) messages, as indicated at block 416 (Fig. 4B). The 
Resv message similarly includes a plurality of objects, including a flow spec object, a 
filter spec object and a session object. The flow spec object, which is similar to the 
sender Tspec object 506 of the Path message 500, specifies the bandwidth that voice 
agent 104 requests to be reserved in order to support the traffic flow from voice agent 
102. The filter spec object, which is similar to the sender Template object 504 of the 
Path message 500, specifies the source address and source port of the traffic flow, while 
the session object, as described above, specifies the destination address and destination 
port of the traffic flow. 

The Resv message travels hop-by-hop back to voice agent 102 following the same 
route used by the Path message 500. At each hop, the Resv message from voice agent 
104 is processed by the respective intermediate network device. More specifically, the 
Resv message is initially received at router 114. The packet/frame receiver transmitter 
object 302 of router 1 14 recognizes the received message as a Resv message and, ac- 
cordingly, passes it to the RSVP engine 316 for processing, as indicated at block 418. 
The RSVP engine 316 first searches its RSVP session table 600 to identify the matching 
entry, e.g., entry 616a, for this Resv message, as indicated at block 420. In particular, the 
RSVP engine 316 looks for an entry of table 600 whose source address, source port, des- 
tination address and destination port match those contained in the received Resv message. 
As described above, a separate entry 616 of table 600 is established for each session. 

Upon locating the matching entry, the RSVP engine 316 derives or computes a 
logical session group ID for this reservation request by concatenating the source address 
with the resource ID value from the cells corresponding to columns 602 and 604 of the 
matching entry, as indicated at block 422. The RSVP engine 316 next determines 
whether another entry of the RSVP session table 600 has the same logical session group 
ID, as indicated at decision block 424. If there is no entry having the same logical ses- 
sion group ID, the RSVP engine 3 1 6 next performs admission control on the reservation 
request, as indicated by No arrow 426 leading to decision block 428. More specifically, 
using the contents of the flowspec spec object, the RSVP engine 316, queries admission 
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control entity 320 to determine whether router 1 14 has sufficient available resources to 
support the requested reservation. RSVP engine 316 may also determine whether or not 
the party making the reservation e.g., voice agent 104, has administrative permission to 
make the reservation specified in the RSVP Resv message. 

5 Assuming the reservation represented by the received Resv message passes ad- 

mission control, the RSVP engine 316 then instructs the packet/frame classification en- 
gine 318 to identify received traffic, i.e., packets, matching the criteria contained in the 
Resv message, such as the filter spec and session spec objects, as indicated at block 430, 
and directs the traffic scheduler 304 to apply the necessary resources to received traffic 

10 matching that criteria to meet the bandwidth requirements contained in the Resv message, 
as indicated at block 432 (Fig. 4C). In other words, the RSVP engine 316 reserves suffi- 
cient resources to support the timing requirements of the session from voice agent 102 to 
voice agent 104. 

Using the stored previous hop address from the matching entry of its RSVP ses- 
is sion table 600, intermediate device 114 then forwards the Resv message to the next hop 
toward the sourcing entity, i.e., toward voice agent 102, as indicated at block 434. If in 
response to decision block 428 (Fig. 4B), the reservation fails admission control, the 
RSVP message generator 322 formulates a reservation error (ResvErr) message and 
sends it back toward the destination/receiving entity, i.e., voice agent 104, as indicated at 
20 block 435 (Fig. 4C). The above described processing of the Resv message is preferably 
repeated at each intermediate device along the route from voice agent 104 to voice agent 
102. 

At this point resources are reserved along the entire route from voice agent 102 to 
voice agent 104 (e.g., at routers 108, 1 10, 1 14 and 1 16) to support the traffic flow con- 
25 taining voice information from voice agent 102 to voice agent 104. It should be under- 
stood that a similar reservation of resources is made in the opposite direction. That is, 
voice agent 104 preferably sends one or more Path messages to voice agent 102, and 
voice agent 102 responds with one or more Resv messages. 

Suppose that while the first party at voice agent 102 is talking to the second party 
30 at voice agent 104, a third party at voice agent 106 places a call to the first party, as indi- 
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cated at block 436. The call signaling entity 210 at voice agent 102 preferably alerts the 
first party of the incoming call, as indicated at block 438. Suppose further that voice 
agent 102 supports call waiting and that the first party decides to place the second party 
on hold and answer the call from the third party, as indicated at block 440. Call signaling 

5 entity 210 detects the first party's transition from the second party, i.e., from voice agent 
104, to the third party, i.e., to voice agent 106, as indicated at block 442. To support the 
anticipated flow of voice traffic from the first party to the third party, which represents a 
new session, the call signaling entity 210 at voice agent 102 directs the RSVP entity 204 
to ensure that sufficient network resources are made available to support this new traffic 

10 flow. 

More specifically, call signaling entity 210 directs the RSVP entity 204 to gener- 
ate and transmit one or more Path messages to voice agent 106, as indicated at block 444. 
However, because the first party will, at any given instant, only be sending voice traffic 
to voice agent 106 or, if he or she switches back to the first call, to voice agent 104, the 

is call signaling entity 210 concludes that the network resources reserved for the session to 
voice agent 104 may be shared with the anticipated session to voice agent 106. Accord- 
ingly, the call signaling entity 210 directs the RSVP entity 204 to configure the reserva- 
tion request such that the previously reserved network resources are shared with the an- 
ticipated session to voice agent 106. In particular, call signaling entity 210 directs RSVP 

20 entity 204 to re-use the same resource ID, i.e., 42578, that was established for the traffic 
flow to voice agent 104 in the Path message to be transmitted to voice agent 106, as also 
indicated at block 444. 

In response, the message generator 206 of RSVP entity 204 creates one or more 
Path messages 500. In fields 558, 560 of the session object 508, the RSVP entity 204 

25 loads the IP address and port number for voice agent 106. In the resource ID field 568 of 
object 510, the RSVP entity 204 loads the same value, i.e., 42578, used in the Path mes- 
sage 500 that was sent to voice agent 104 as described above. RSVP entity 204 then 
passes the Path message 500 to communication facility 202 for transmission to voice 
agent 106 via network 100, as indicated by block 446 which returns processing to block 

30 408 (Fig. 4 A). As indicated by blocks 410-414, at each hop along the route to voice 
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agent 106, the respective intermediate network device processes the Path message. In 
particular, each device creates a new entry, e.g., entry 616e, in its RSVP session table 600 
and stores the information contained in the Path message 500 in that new entry. Each 
intermediate device also loads its IP address into the previous hop object before for- 
5 warding it to the next intermediate network device along the route. 

Voice agent 106 preferably responds to the Path message 500 from voice agent 
102 by generating one or more RSVP Resv messages, as indicated at block 416 (Fig. 4B). 
The Resv message travels hop-by-hop back to voice agent 102 following the same route 
used by the Path message 500 that traveled from voice agent 102 to voice agent 106. At 

10 each hop, the Resv message from voice agent 106 is processed by the respective interme- 
diate network device. More specifically, the Resv message is initially received at router 
116. The packet/frame receiver transmitter object 302 of router 116 recognizes the re- 
ceived message as a Resv message and, accordingly, passes it to the RSVP engine 3 16 
for processing, as indicated at block 418. The RSVP engine 316 first searches its RSVP 

is session table 600 to identify the matching entry, i.e., entry 61 6e, for this Resv message, 
as indicated at block 420. 

Upon locating the matching entry, the RSVP engine 316 computes or derives a 
logical session group ID for this reservation request by concatenating the source address 
and the resource ID as contained in the cells of entry 616e corresponding to columns 602 

20 and 604, as indicated at block 422. The RSVP engine 316 next determines whether an- 
other entry of the RSVP session table 600 has the same logical session group ID, as indi- 
cated at decision block 424. Because the same resource ID value, i.e., 42578, was used in 
the previous Path message 500 from voice agent 102 to voice agent 104, there will be at 
least one matching entry, i.e., entry 616a. In response to detecting a matching entry, 

25 router 116 considers the two sessions from voice agent 102 (i.e., the traffic flow to voice 
agent 104 and the traffic flow to voice agent 106) to belong to the same group, as indi- 
cated by Yes arrow 448 leading to block 450 (Fig. 4D). If the resources previously allo- 
cated to this group are sufficient to support the new session (e.g., if the first and second 
session require the same amount of bandwidth), RSVP entity 316 does not perform ad- 

30 mission control on the reservation request contained in the Resv message from voice 
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agent 106, as indicated at block 452. It also does not reserve additional resources to sup- 
port the voice traffic from voice agent 102 to voice agent 104, as also indicated at block 
452. 

Once it has been established that the correct amount of resources is available, 
5 RS VP entity 316 directs the packet/frame classification engine 3 1 8 to identify received 
traffic, i.e., packets, matching the criteria contained in the Resv message from voice agent 
106, such as the filter spec and session objects, as indicated at block 454, and directs the 
traffic scheduler 304 to apply the resources previously reserved for the session from 
voice agent 102 to voice agent 104 to be applied to this session, i.e., to the traffic flow 
10 from voice agent 102 to voice agent 106, as indicated at block 456. Thus, the network 
resources reserved to support the session to voice agent 104 are shared with the session to 
voice agent 106. Router 116 then forwards the Resv message to the next hop toward the 
sourcing entity, i.e., toward voice agent 102, as indicated at block 458. 

It should be understood that the RSVP engines 316 of the intermediate network 
15 devices may also confirm that resources have already been reserved and assigned to the 
matching traffic flow before determining that the two sessions may share the same re- 
sources. If resources have not yet been reserved to the prior session, then the RSVP en- 
gines 316 perform admission control and reserve resources for the subsequent session in 
a conventional manner. Furthermore, if the resources required by the new session exceed 
20 those currently allocated to the prior session, then the incremental resources need to be 
reserved. In this case, admission control is required. 

It should be understood that voice agents 102, 104, 106 periodically issue Path 
and Resv messages in order to refresh the soft states maintained by the state machine en- 
gines 324 of the network devices. The Path messages used to refresh RSVP state pref- 
25 erably contain the same resource ID used in the first Path message for the respective ses- 
sion. Accordingly, each voice agent 102, 104, 106 preferably stores the resource IDs in 
use by them. 

Intermediate network devices that have not been configured to recognize the re- 
source ID object 510 simply process the Path messages containing such objects in a con- 
30 ventional manner. That is, these legacy devices look for entries matching the session ID 
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of received Resv messages and do not share resources among different sessions, even if 
those sessions will not be transmitting traffic at the same time. 

It should further be understood that the present invention can be used with other 
reservation or signaling protocols besides RSVP. For example, the present invention can 
5 be advantageously used with ATM signaling protocols, such as Q.293 1 . 

It should be further understood that the resource ID generator 212 may be dis- 
posed at or otherwise be accessible to the call signaling entity 210. In this case, the call 
signaling entity 210 would generate the resource ID and pass it to the RSVP entity 204 
for use in RSVP reservation requests. The resource ID values could also be alphanu- 
io meric strings or other locally unique values. 

It should also be understood that the present invention can be implemented with 
other voice agents, such as personal computers (PCs) running one or more communica- 
tion applications that include RSVP support, such as NetMeeting from Microsoft Corp. of 
Redmond, Washington and/or Intel Internet Phone from Intel Corp. of Santa Clara, Cali- 
is fornia. VoIP or Internet telephones may also be used as voice agents in the manner de- 
scribed herein. 

Also, it should be understood that the voice traffic described herein may be ex- 
changed between multimedia terminal adapters coupled to cable modems, which, in turn, 
are connected to a cable network. In this case, the corresponding cable modem termina- 
20 tion systems (CMTSs) would generate the Path messages containing the resource ID ob- 
jects 510. 

The foregoing description has been directed to specific embodiments of this in- 
vention. It will be apparent, however, that other variations and modifications may be 
made to the described embodiments, with the attainment of some or all of their advan- 
25 tages. For example, the present invention can be used with other time-sensitive or high 
bandwidth traffic flows besides voice, such as video or multimedia traffic flows. There- 
fore, it is an object of the appended claims to cover all such variations and modifications 
as come within the true spirit and scope of the invention. 

What is claimed is: 
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